well I think, we should not have to document it
it should be self explaining, by the UI to only show options that are posible...

• any user can create a pull to a repo as long as it's visibe to them
• codeWrite permission allow you to merge beside protected branch is protecting from merging
• auto-merge can be scheduled/cancled by codeWrite permission
• admins & owners can merge (with red button) with bypassing protected branch rules - but also are able to schedule/cancle auto-merge

(code already describe it that way but UI does not ...)

well I think, we should not have to document it

However, if I am a frontend developer, how can I read a lot of backend code to understand how it works ...... even if the backend code might become incorrect during refactoring .....

I also think the UI/UX may make somebody confusing. I suggest we have more discuss about that. And I think the auto merge should also require the base branch is updated?

Please propose non-confusing UI/UX

First, How about to make the state machine

graph TD;
      A[Manual Merge] --> B[Auto Merge];
      B --> C[Cancel Merge];
      C --> A;

I do not think that an admin should have to cancel an scheduled auto merge before they do a normal merge. The admin should be able to bypass the checks and scheduled auto merge, then do the normal merge in one click.

But if you prefer to change the logic, there is no blocker from my side, edit on this PR directly.

I do not think that an admin should have to cancel an scheduled auto merge before they do a normal merge. The admin should be able to bypass the checks and scheduled auto merge, then do the normal merge in one click.

But if you prefer to change the logic, there is no blocker from my side, edit on this PR directly.

You are right. Admin should not be blocked by that. But I think that's what the complicated thing. We have to put both manually merge and auto merge in the UI in that situation and have to have a lock between manual merge and auto merge. To avoid that, we can simplify the process.

I'm not sure if this is the right direction. Just my thought and more ideas are welcome.

About this PR, I think it should either:

• get merged in 1.17 and be improved later.
• (OR) get improved before 1.17-rc and get merged in 1.17

Otherwise these already merged backend code and translations would become dead code and might be more difficult to be maintained in the future.

@techknowlogick Do you prefer to move it to 1.18? Can you help me to know the reasons? already discussed in discord. wait for some design feedbacks.

Some UI adjustments (shorten the texts)

I think the merge style should be decided when starting to auto merge. The change of merge style should not be allowed before cancel the auto merge.

🚀